Test automation may use software programs to control execution of tests of software applications and/or software products. Test automation tools may support automated tasks such as product installation, test data creation, UI interaction, problem detection (such as parsing, polling agents, etc.), defect logging, comparison of actual outcomes to predicted outcomes, setting up of test pre-conditions, and/or other test control and/or test reporting functions.
Test automation may involve automating a (partly) manual process. Although manual tests may find some deficits in a software application, it is a laborious and time consuming process. Testing large software applications would hardly be possible to be tested manually in a reliable manner.
In particular, testing software applications manually may be an expensive and time consuming process, which in the end may cover only some aspects of test scenarios for a software application or product to be tested. Test automation may relate in principle to a process aiming at reducing the testing effort by using software to generate, maintain and/or run automated test scenarios (or tests). For this purpose, test automation tools may commonly provide features to record a test scenario for a software application, store the recorded events and replay them back. Such an approach may be applied to applications including a graphical user interface. However, a plurality of technical constraints may limit the reliability of the generated tests which may be very sensitive to changes performed on software applications to be tested. Changes may comprise for example, changing the location of the control in its parent container, renaming its text or its label, and/or changing the user language.
In other words, test automation tools may also record native events raised by the operating system (OS) while using the graphical user interface (GUI) of a software application. Hence, software applications may be tested via their GUIs. This approach is widely adapted by automated testing tools. A drawback of this approach may be that the generated tests may not only be sensitive to the underlying UI technology, but also to user preferences and/or OS-specific settings.
Furthermore, test maintenance may require deep technical knowledge to adapt to software changes. In some situations a scenario for testing purpose (e.g. test cases/test scenarios) needs to be recorded again. Test Frameworks may partly solve test maintenance issues due to the concept of test composition. Using test frameworks, the test cases may be created by aggregating test components. Test components may refer to reusable blocks representing an atomic operation of a software application to be tested. The testing software application may in this case be operable to simply adapt the parameters of each component occurrence without any deep technical knowledge.
An alternative to the above described approach may be based on bypassing the GUI layer of the software application to be tested and to directly test the application via its remote application programming interface (API).
In order to use this approach and still benefit from the ability to use test composition (i.e. composing test components according to a test scenario) a test framework may need to deliver a component per method exposed by the API. Even though most of the components are similar, creating those components manually may be a very tedious task, especially when several implementations are necessary depending on the targeted test framework and/or the underlying scripting language.
Using the second approach, another problem may occur. A testing software application (or tester) using a test framework may create tests/test scenarios by aggregating test components, wherein each test component may expect some input parameters. The test framework (comprising test automation) may only provide input parameters using simple types (e.g. integer, real, long, string, etc.). As a consequence, a method expecting a complex object (e.g. a list, an array, etc.) as input parameter cannot be used by the tester. Therefore, test automation using the second approach and thereby merely generating a wrapper on top of the target object may not solve the problem with regard to the input parameters.
Hence, there is a need to provide a computer-implemented method, a system and a computer program product referring to a test automation tool which reduces an implementation and maintenance effort of automatically testing software applications independent from any input parameters. Furthermore, the testing software application should be able to test a business logic according to an object model underlying a software application and/or a software product without any deep technical knowledge and to maintain previously recorded tests and hence without losing the benefit of test composition.